fix(desktop): renderer boot error boundary and electron hardening by charlesvien · Pull Request #2816 · PostHog/code

charlesvien · 2026-06-21T00:14:49Z

Problem

Two reliability and security gaps from the package split surfaced, deliberately split out from #2813 because they touch runtime-sensitive Electron config and warrant their own review.

If boot(), a module-scope import or an Inversify resolution throws during renderer startup, the user gets a blank window with no error and no recovery short of force-quitting.
The main window runs with nodeIntegration: true, which applies in production, not just dev.

Changes

Add a BootErrorBoundary (apps/code/src/renderer/components/BootErrorBoundary.tsx) around the root React tree, plus a try/catch around the synchronous bootstrap in main.tsx and a .catch on the async boot(container). Any of those failing now renders a minimal, theme-independent error screen with a Reload button instead of a blank window, and logs the failure.
Set webPreferences.nodeIntegration: false on the main window. contextIsolation: true is already set (so the renderer main world never had Node anyway) and the renderer is Vite-bundled with zero node:*/require usage in the main world, so this is defense in depth with no functional change.

Scope note: the dev-only webSecurity: false override is left in place. It does not affect production (production already runs with webSecurity: true) and flipping it risks breaking dev resource loading. The remaining dev/prod parity gap is deferred.

How did you test this?

All run locally in the branch worktree:

pnpm typecheck: 22/22 packages pass
pnpm lint: clean
pnpm test: apps/code 151 pass
node scripts/check-host-boundaries.mjs: no new violations

Not yet done: a manual smoke test of the running app (dev and packaged). The nodeIntegration flip is low risk given contextIsolation: true, but it changes runtime Electron config, so a human should confirm the window still loads and agents/terminals work before merge. This PR is left as a draft for that reason.

Automatic notifications

Publish to changelog?
Alert Sales and Marketing teams?

charlesvien · 2026-06-21T00:15:03Z

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

github-actions · 2026-06-21T00:15:19Z

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit ba3c8e7.}

greptile-apps · 2026-06-21T00:17:07Z

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/code/src/renderer/main.tsx:97-99
When `boot(container)` rejects, the `.catch()` only logs the error but the already-mounted React tree continues to run. Users either see a broken app or, if the boot failure cascades into a render crash, a `BootErrorBoundary`-generated message that doesn't match the root cause. The synchronous failure path (the outer `catch`) correctly renders `BootErrorScreen`; the async path should do the same.

```suggestion
  boot(container).catch((error: unknown) => {
    bootLog.error("Renderer boot sequence failed", error);
    root.render(<BootErrorScreen error={error} />);
  });
```

_{Reviews (1): Last reviewed commit: "harden renderer boot and electron securi..." | Re-trigger Greptile}

greptile-apps · 2026-06-21T00:34:01Z

_{Reviews (2): Last reviewed commit: "harden renderer boot and electron securi..." | Re-trigger Greptile}

github-actions

No showstoppers. Security hardening (nodeIntegration: false) is correct given contextIsolation: true and a preload script were already in place. The boot error boundary and async failure handling are well-structured fixes. The resolved bot comment was addressed.